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Calendar Attributes for vCard and LDAP 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and reguests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 
When scheduling a calendar entity, such as an event, it is a 
prerequisite that an organizer has the calendar address of each 
attendee that will be invited to the event. Additionally, access to 
an attendee's current "busy time" provides an a priori indication of 
whether the attendee will be free to participate in the event. 
In order to meet these challenges, a Calendar user agent (CUA) needs 
a mechanism to locate (URI) individual user" s calendar and free/busy 


time. 


This memo defines three mechanisms for obtaining a URI to a user's 
calendar and free/busy time. These include: 


— Manual transfer of the information; 
— Personal data exchange using the vCard format, and 


— Directory lookup using the LDAP protocol. 
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1 Calendaring and Scheduling URIs 


This memo defines four classes of URIs. URIS are more useful if it is 
understood what the URIs point to. Here is a brief description: 


1.1 Free/Busy URI (FBURL) 


The free/busy URI is defined to be a transport independent location 
where a client can obtain information about when a user is busy. At 
the present time, this URI only points to busy time data. Future 
revisions of this specification may provide for the extended 
capability of publishing free time data. 


If a calendaring and scheduling client (i.e., CUA) were to retrieve 
data from this location using FTP or HTTP, it would get back an 
iCalendar object [4] containing one or more "VFREEBUSY" calendar 
components. If a MIME transport is being used, the response will be 
contained within a "text/calendar" MIME body part as specified in the 
iCalendar specification [4]. For example: 


BEGIN: VCALENDAR 

VERSION: 2.0 
PRODID:-//hacksw/handcal//NONSGML v1.0//EN 
METHOD: PUBLISH 

BEGIN: VFREEBUSY 

ATTENDEE :MAILTO: jane doeGehost1.com 
DTSTART:19971013T0500002 
DTEND:19971124T050000Z 
DTSTAMP:19970901T0830002 

FREEBUSY :19971015T1330002/19971015T1800002 
FREEBUSY :19971015T1900002/19971015T2200002 
FBURL:http://www.host.com/calendar/busy/jdoe.ifb 
END: VFREEBUSY 

END : VCALENDAR 


The amount of busy time data pointed to by the FBURL will generally 
be pre-determined; for example one month of busy time data. As a 
guideline, it is recommended that the previous six weeks of busy time 
data be published at the location associated with the FBURL. If this 
URI points to a file resource, it is recommended that the file 
extension be "ifb" to distinguish it from an arbitrary iCalendar 
object (e.g., with the "ics" file extension). 
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1.2 Calendar Access URI (CAPURI) 


The Calendar Access URI is defined to be a protocol independent 
location from which a calendaring and scheduling client (i.e., CUA) 
can communicate with a user's entire calendar. 


The semantics for using this URI as an access protocol locator are 
yet to be defined by the IETF CALSCH Working Group. This will be 
addressed in the "Calendar Access Protocol" specification. 


1.3 Calendar URI (CALURI) 


The Calendar URI is defined to be a protocol independent location 
from which a calendaring and scheduling client (i.e. CUA) can 
retrieve an entire copy of a user's calendar. Retrieving data from 
this URI obtains a published "snapshot" of the user's calendar. 


HTTP URI -- If the URI is an HTTP URI, then the content returned with 
a GET should be a "text/calendar" MIME body part containing one or 
more iCalendar object. 


FTP URI -- If the URI is an FTP URI, then the resource pointed to 
should be a file with an "ics" file extension containing one or more 
iCalendar objects. 


1.4 Default URls 


There are many cases where a user may have more than one calendar. In 
these cases, a user may have multiple URIs, each URI pointing to a 
calendar or free/busy data. 


To make the case of multiple calendars simpler for clients, the 
concept of the "default" calendar is introduced. A "default" calendar 
is one that the user has designated as the calendar that other users 
should look at when accessing the user's calendar, or retrieving the 
user's free/busy time. 


The default calendar may, in fact, include rolled-up information from 
all the user's other calendars. The other calendars may only exist 
for organizational purposes. 


2 Distribution 


These four URIs provide valuable pointers to calendaring and 
scheduling data that other users need in order to know when to 
schedule meetings, etc. There are several possibilities on how users 
can communicate these URIs to other users. The following section 
outlines how these URIs can be distributed to other users. 
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2.1 Manual Transfer 


The simplest way to obtain these URIs is for a user to communicate 
the URIs using some out-of-band mechanism such as verbally, or in an 
e-mail message, or by printing these URIs on a paper business card. 


When using this mechanism, the user obtains these URIs using an out- 
of-band mechanism and then enters these URIs into their calendaring 
software manually. 


2.2 Personal Data Exchange Using A vCard 


A more sophisticated way to obtain these URIs is for users to publish 
vCards containing these URIs. The vCard object can be transferred 
between one another. Since many e-mail clients allow a user to 
automatically include a vCard with every message that the user sends, 
this provides a simple, transparent way for a user to distribute 
their calendaring and scheduling URIs. 


On the receiving end, an e-mail client that provides an integrated 
vCard database can provide a way to lookup calendaring URIs for users 
whose vCards are stored locally. 


2.3 vCard Schema Extensions 


Since the vCard [3] specification doesn’t specify how to encode 
calendaring URIs in a vCard, this section is provided as an extension 
to vCard which specifies how to encode calendaring URIs within a 
vCard. 


Inside a vCard object, four new properties are defined: "CALURI", 
"CAPURI", "CALADRURI", and "FBURL", as defined above. 


Any vCard can have one or more of these properties, each representing 
a calendar or free/busy time that is associated with the user. 


One of these properties can be designated as the "default" by adding 
the "PREF" parameter. 
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Here is a simple example of a vCard containing a "FBURL" and a 
"CALURI". 


BEGIN:VCARD 

VERSION: 3.0 

N:Dun;Alec 

FN:Alec Dun 

ORG:Microsoft Corporation 

ADR; WORK; POSTAL; PARCEL:;;One Microsoft Way; 
Redmond; WA; 98052-6399; USA 

TEL; WORK; MSG: +1-206-936-4544 

TEL; WORK; FAX: +1-206-936-7329 

EMAIL: INTERNET: user@host1l.com 
CALADRURI; PREF: mailto:user@hostl.com 
CALURI;PREF:http://cal.hostl.com/user/cal.ics 
FBURL; PREF :http://cal.host1.com/user/fb.ifb 
CALURI:http://cal.company.com/projectA/pjtA.ics 
FBURL:http://cal.company.com/projectA/pjtAfb.ifb 
END : VCARD 


2.3.1 FBURL Property IANA Registration 
To: ietf-mime-directory@imc.org 


Subject: Registration of FBURL type for text/directory MIME type 
vCard profile. 


Type name: FBURL 


Type purpose: To specify the URI for a user's busy time in a vCard 
object. 


Type encoding: 8bit 

Type value: A single URI value. 

Type special notes: Where multiple FBURL properties are specified, 
the default FBURL property is indicated with the PREF parameter. The 
FTP or HTTP type of URI points to an iCalendar object associated with 
a snapshot of the last six weeks of the user's busy time data. If the 
iCalendar object is represented as a file or document, it's file type 


should be "ifb". 


Intended usage: Refer to section 1.1. 
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Type examples: 


FBURL;PREF:http://www.host1.com/busy/janedoe 
FBURL:FTP://ftp.host.com/busy/project-a.ifb 


2.3.2 CALADRURI Property IANA Registration 
To: ietf-mime-directory@imc.org 


Subject: Registration of CALADRURI type for application/directory 
MIME type vCard profile. 


Type name: CALADRURI 


Type purpose: To specify the location to which an event request 
should be sent for the user. 


Type encoding: 8bit 

Type value: A single URI value. 

Type special notes: Where multiple CALADRURI properties are 
specified, the default CALADRURI property is indicated with the PREF 
parameter. 

Intended usage: Refer to section 1.2. 


Type examples: 


CALADRURI; PREF :mailto: janedoe@host.com 
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2.3.3 CAPURI Property IANA Registration 
To: ietf-mime-directory@imc.org 


Subject: Registration of CAPURI type for application/directory MIME 
type vCard profile. 


Type name: CAPURI 

Type purpose: To specify a protocol independent location from which a 
calendaring and scheduling client (i.e., CUA) can communicate with a 
user's entire calendar. 

Type encoding: 8bit 


Type value: A single URI value. 


Type special notes: Where multiple CAPURI properties are specified, 
the default CAPURI property is indicated with the PREF parameter. 


Intended usage: Refer to section 1.3. 
2.3.4 CALURI Property IANA Registration 
To: ietf-mime-directory@imc.org 


Subject: Registration of CALURI type for text/directory MIME type 
vCard profile. 


Type name: CALURI 


Type purpose: To specify the URI for a user's calendar in a vCard 
object. 


Type encoding: 8bit 

Type value type: A single URI value. 

Type special notes: Where multiple CALURI properties are specified, 
the default CALURI property is indicated with the PREF parameter. The 
property should contain a URI pointing to an iCalendar object 
associated with a snapshot of the user's Calendar store. If the 
iCalendar object is represented as a file or document, it's file type 


should be "ics". 


Intended usage: Refer to section 1.4. 
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Type examples: 


CALURI: PREF :http://cal.host1.com/calA 
CALURI:ftp://ftp.hostl.com/calA.ics 


2.4 Directory Lookup Using The LDAP v3 Protocol 


Another way to obtain these URIs is to look them up in a directory 
using the LDAP protocol [1]. 


If a user" s URIs can be found using directory lookup (i.e., searching 
for one of the LDAP schema extensions defined below), they should, in 
general, be considered "more up-to-date" than URIs in any vCards that 
are stored locally. 


2.4.1 LDAP Schema Extensions 


In order to encode the calendaring URIs in the directory, the 
following are defined: 


— One object class: 
— calEntry 


— Eight attributes: 


calCalURI 


— calFBURL 


— calCAPURI 


— calCalAdrURI 


— calOtherCalURIs 


— calOtherFBURLS 


— calOtherCAPURIS 


calOtherCalAdrURIs 


The calCalURI contains the URI to a snapshot of the user's entire 
default calendar. The calFBURL contains the URI to the user's default 
busy time data. The calCAPURI represents contains a URI that can be 
used to communicate with the user's calendar. The calCalAdrURI 
contains a URI that points to the location to which event requests 
should be sent for that user. 
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The calOtherCalURIs is a multi-valued property containing URIs to 
snapshots of other calendars that the user may have. The 
calOtherFBURLs is a multi-valued property containing URIs to other 
free/busy data that the user may have. The calOtherCAPURIs attribute 
is a multi-valued property containing URIs to other calendars that 
the user may have. The calOtherCalAdrURIs attribute is a multi-valued 
property containing URIs to other locations that a user may want 
event requests sent to. 


There is no predetermined order to the values in either multi-valued 
property. 


2.4.2 Notation 

The notation used in this memo is the same as that used in [2]. 
2.4.3 Object Definitions 
2.4.3.1 calEntry 


The Calendar Entry is a class derived from "TOP" [2], which contains 
the four calendaring attributes. 


(1.2.840.113556.1.5.87 
NAME "calEntry" 
TOP 
AUXILIARY 
MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs calCAPURI 
calOtherCAPURL.s) 


2.4.4 Attribute Definitions 
2.4.4.1 calCalURI 


(1.2.840.113556.1.4.478 
NAME "calCalURI" 
EOUALITY caselgnoreMatch 
SUBSTRING caselgnoreMatch 
SYNTAX " IA5String"! 
USAGE userApplications 


) 
2.4.4.2 calFBURL 
(1.2.840.113556.1.4.479 


NAME 'calFBURL” 
EOUALITY caselgnoreMatch 
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SUBSTRING caselgnoreMatch 
SYNTAX ’TA5String’ 
USAGE userApplications 


calCAPURI 


1.2.840.113556.1.4.480 
NAME "calCAPURI" 

EOUALITY caselgnoreMatch 
SUBSTRING caselgnoreMatch 
SYNTAX " IA5String"! 

USAGE userApplications 


calCalAdrURI 


1.2.840.113556.1.4.481 
NAME "calCalAdrURI" 
EOUALITY caselgnoreMatch 
SUBSTRING caselgnoreMatch 
SYNTAX " IA5String"! 

USAGE userApplications 


calOtherCalURIs 


(1.2.840.113556.1.4.482 
NAME "calOtherCalURIs" 
EQUALITY caseIgnoreMatch 
SUBSTRING caseIgnoreMatch 
SYNTAX " IA5String"! 
MULTI-VALUE 

USAGE userApplications 


calOtherFBURLS 


1.2.840.113556.1.4.483 
NAME "calOtherFBURLs" 
EQUALITY caseIgnoreMatch 
SUBSTRING caselgnoreMatch 
SYNTAX ’TA5String’ 
MULTI-VALUE 

USAGE userApplications 
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2.4.4.7 calOtherCAPURls 


(1.2.840.113556.1.4.484 
NAME "calOtherCAPURISs" 
EOUALITY caselgnoreMatch 
SUBSTRING caselgnoreMatch 
SYNTAX " IA5String"! 
MULTI-VALUE 
USAGE userApplications 

) 


2.4.4.8 calOtherCalAdrURIs 


(1.2.840.113556.1.4.485 
NAME "calOtherCalAdrURIs" 
EOUALITY caselgnoreMatch 
SUBSTRING caselgnoreMatch 
SYNTAX " IA5String"! 
MULTI-VALUE 
USAGE userApplications 

) 


3 IANA Considerations 


This memo defines IANA registered extensions to the attributes 
defined by LDAP [1] and vCard [3]. 


IANA registration proposals for vCard are to be emailed to the 
registration agent for the "text/directory" MIME content-type, 
<MAILTO: ietf-mime-directory@imc.org> using the format defined in 
[3]. 


4 Security Considerations 


Standard vCard and LDAP security rules and support apply for the 
extensions described in this document, and there are no special 
security issues for these extensions. 


Please note, though, that LDAP servers may permit anonymous clients 
to refresh entries which they did not create. Servers are also 
permitted to control a refresh access to an entry by requiring 
clients to bind before issuing a RefreshRequest. This will have 
implications on the server performance and scalability. 


Please also note, though, that vCard objects may have been created by 


an entity other than that represented by the vCard. Recipients should 
be certain of the source that generated the vCard. 


Small, et al. Standards Track [Page 12] 


RFC 2739 Locating a Calendar User January 2000 


Also, care should be taken in making use of information obtained from 
directory servers that has been supplied by client, as it may now be 
out of date. In many networks, for example, IP addresses are 
automatically assigned when a host connects to the network, and may 
be reassigned if that host later disconnects. An IP address obtained 
from the directory may no longer be assigned to the host that placed 
the address in the directory. This issue is not specific to LDAP or 
dynamic directories. 
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6 Authors’ Addresses 


The following address information is provided in a vCard v3.0 [3], 
Electronic Business Card, format. 


BEGIN: VCARD 

VERSION:3.0 

N: Small; Tony 

FN: Tony Small 

ORG: XpertSite.Com 

ADR; TYPE=WORK, POSTAL, PARCEL:;;4700 42nd Ave. SW, Suite 440; 
Seattle; WA; 98116: USA 

TEL; TYPE=WORK, MSG: +1-206-937-9972 

TEL; TYPE=WORK, FAX: +1-206-936-7329 

EMAIL; TYPE=INTERNET: tony@xpertsite.com 

CALADRURI:MAILTO:tony@xpertsite.com 

END : VCARD 


BEGIN: VCARD 

VERSION: 3.0 

N: Hennessy; Denis 

FN:Denis Hennessy 

ORG: ISOCOR 

ADR; TYPE=WORK, POSTAL, PARCEL:;;42-47 Lower Mount St; 
Dublin 2;Ireland 

TEL; TYPE=WORK, MSG: +353-1-676-0366 

TEL; TYPE=WORK, FAX: +353-1-676-0856 

EMAIL; TYPE=INTERNET:denis.hennessy@isocor.com 
CALADRURI:MAILTO:denis.hennessy@isocor.com 
END : VCARD 
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BEGIN: VCARD 

VERSION: 3.0 

N:Dawson; Frank 

FN:Frank Dawson 

ORG: Lotus Development Corporation 

ADR; TYPE=WORK, POSTAL, PARCEL:;; 6544 Battleford Drive; 
Raleigh;NC;27613-3502;USA 

TEL; TYPE=WORK, PREF :+1-617-693-8728 

TEL; TYPE=WORK, MSG: +1-919-676-9515 

TEL; TYPE=FAX:+1-617-693-8728 

EMAIL; TYPE=INTERNET, PREF:Frank_Dawson@Lotus.com 
EMAIL: TYPE=INTERNET: fdawson@earthlink.net 
CALADRURI; TYPE=PREF :MAILTO: Frank DawsonGlLotus.com 
CALADRURI : MAILTO: fdawson@earthlink.net 

URL:http://home.earthlink.net/” fdawson 

END: VCARD 


This memo is a result of the work of the Internet Engineering Task 
Force Calendaring and scheduling Working Group. The chairman of that 
working group is: 


BEGIN: VCARD 

VERSION: 3.0 

N:Egen; Pat 

FN:Pat Egen 

ORG:Engan Consulting 

ADR; TYPE=WORK:;;803 Creek Overlook; Chattanooga; TN, 37415, USA 
TEL; TYPE=WORK, VOICE: 423.875.2652 

TEL; TYPE=WORK, FAX: 423.875.2017 

EMAIL: pregen@egenconsulting.com 

URL: http: //www.egenconsulting.com 
CALADRURI :MAILTO:pregen@egenconsulting.com 
END: VCARD 
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8 Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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